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(54) System for deploying location-based services 



(57) A method of deploying location based services 
executable on different clients (1) of a client-server sys- 
tem comprises the following steps: transferring service 
correlated data from a server to said clients (1 ) on the 
basis of a push mechanism which works independent 
with respect to activities performed on said clients, said 
service correlated data including location-service linking 



information, processing said location -service linking in- 
formation on the clients (1), thereby assigning locations 
to services and/or services to locations, executing said 
services on the basis of said assignments between lo- 
cations and services. Thus, the server and the clients 
(1) can be decoupled, which reduces the communica- 
tion effort between the server and the clients (1). 
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Description 

[0001 ] The invention relates to a method of deploying 
location-based services, and a client, a server and a cli- 
ent-server system suitable to perform said method. 
[0002] Location-based services are services which 
are associated with a location. A location-based service 
may for example be a service which informs a user 
about traffic events in a location-dependent manner. If 
users are conditioned by the natural environment to 
process location-based information, offering location- 
based services provides a means to filter and group 
services according to the interest of the user. 
[0003] Systems providing location based services 
typically are an extension of a geographical information 
system (GIS). In such systems not only geographical 
data is presented to the user, but also additional infor- 
mation or services (for example opening times of a res- 
taurant, a description of a site, or the possibility for a 
user to make a reservation for a hotel) are available. 
While parts of services/service correlated data might be 
offered as stand-alone solution, it is important especially 
for highly dynamic service correlated data to externalize 
respective information sources providing said service 
correlated data. 

[0004] To enable an externalization of information 
sources, usually a pull architecture is used being based 
on a client-server architecture (see for example [8], [9], 
[20], [21], [22] and [26]). Using this architecture, the user 
issues a request with respect to a service by using a 
client like a handheld or a mobile phone, wherein the 
request is passed to a server. The server then process- 
es the request. To provide location-dependent service- 
correlated information, location information about the lo- 
cation of the user has to be included within the request 
or has to be determined by the server itself. In depend- 
ency of the issued request, service-correlated data is 
assembled by the server, which is returned to the client. 
The service-correlated data transferred to the client is 
presented to the user. If mobile clients are used, gener- 
ally different gateways on the server's side have to be 
used which differ in terms of bandwidth and cost (gate- 
ways for WAP [23], SMS [24] or mobile internet are dif- 
ferent from each other). 

[0005] However, using such an architecture has two 
major problems: 

Privacy: The user has to disclose his/her position to 
the server. 

Costly scalability regarding communication band- 
width and server: As a unicast medium is used, the 
service-correlated data has to be provided individ- 
ually in terms of connection and transaction be- 
tween the server and the clients. This is also true 
for service-correlated data being requested by 
many users. An additional proxy server for fetching 
and storing service-correlated data of common in- 
terest for users of a particular domain may relieve 
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the load of the server, but the problem of sharing a 
unicast communication link to the server between 
many users is even stronger. 

5 [0006] Other problems, in particular related to the cur- 
rent deployment of above described client-server sys- 
tems are: 

Inflexibility: Services are normally tailored to a sin- 
10 gle or a few domains. 

No interoperability: It is difficult to combine above 
described client-server systems with other sys- 
tems. 

15 

If mobile clients are used, the service-correlated da- 
ta has to be fitted in accordance with a low band- 
width. 

20 - it is difficult to reuse existing services which are not 
location-based since location-specific data cannot 
be separated from general application content (see 
for example [18]). 

25 [0007] It is an object of the present invention to pro- 
vide a system for location-based services which avoids 
the privacy problem described above while at the same 
time providing a lean architecture. 
[0008] To solve this object, the present invention pro- 
30 vides a method of deploying location-based services ac- 
cording to claim 1 . Further, the invention provides a cli- 
ent for deploying location-based services according to 
claim 8. Further, the invention provides a server being 
connectable to clients according to claim 16. 
35 [0009] Last, the invention provides a client-server 
system for deploying location-based services according 
to claim 19. A computer program product according to 
the present invention is defined in claim 20. Preferred 
embodiments of the present invention are respectively 
40 described in respective subclaims. 

[0010] In the following some terms will be explained 
which are used within the description. 
[0011] A "service" is a kind of activity provided by a 
client to a user in order to fulfill some need. Viewed from 
45 the client's side, it is the behaviour of the application. 
Applications are the technical means to realize services. 
They are composed of three components, namely the 
application code, the application engine and the appli- 
cation content. The application engine is used to exe- 
so cute the application code, so that the user can interact 
with the application (for example a HTML-page can be 
regarded as application code which is rendered by a 
web browser as its application engine). The application 
content is to be regarded as the flexible part of the ap- 
55 plication (in the case of a GIS-application the application 
content is for example map data). 
[0012] A "location" is any form of description which re- 
fers to a virtual or physical place. A virtual location is an 
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abstraction of reality, for example a map or a reference 
to a map or a reference to a point on a map. A service 
(application) is location-based if the service is either in- 
volved in dealing with locations (for example a naviga- 
tion system) or if the service is activated in dependence 
of a location related to the service (e. g. the web site of 
a bakery might be connected to a certain location). 
[0013] Location-service linking means associating a 
location with a service and/or associating a service with 
a location. This is a true n-to-n relationship, as a service 
might be associated with several locations, and a loca- 
tion might be associated with several services. Loca- 
tion-service linking is represented by location-service 
linking information. 

[001 4] Using the above described terminology, the in- 
vention provides a method of deploying location-based 
services executable on different clients of a client-server 
system, which comprises the steps of: 

transferring service correlated data from a server to 
said clients on the basis of a push mechanism which 
works independent with respect to activities per- 
formed on said clients, said service-correlated data 
including location-service linking information, 
processing said location-service linking information 
on the clients, thereby assigning locations to serv- 
ices and/or services to locations, 
executing said services on the basis of said assign- 
ments between locations and services. 

[001 5] Client-server systems which use a push mech- 
anism to transfer information from the server to the client 
may be classified into two categories: 

the server transfers ("pushes") the information into 
information channels without knowing which clients 
are connected to this information channels and will 
pick up therefore this information; the act of pushing 
is not initiated by the clients but only by the server 
itself since the server does not "know" anything 
about the clients (no information is transferred from 
the client to the server). An example is radio broad- 
casting: the server (transmission station) sends in- 
formation without knowing which receivers will pick 
up said information. The act of sending information 
by the transmission station is not initiated by the re- 
ceivers. 

the server transfers ("pushes") the information into 
information channels knowing which clients will pick 
up this information, since the clients previously 
have informed the server which information channel 
is associated with them. As in the previous category, 
the clients do not have any influence upon which 
information is sent to the clients (information is iden- 
tical for all clients) and when this information is sent. 
However, they have an influence upon if information 
is sent at all. An example is subscribing at the server 
by specifying a client-specific e-mail account, re- 
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spectively, to which the information has to be sent. 
Thus, information is sent from the clients to the serv- 
er. The push mechanism according to the present 
invention belongs to the first category. 

5 

[0016] The inventive method allows to avoid the pri- 
vacy problem described above, since the clients and the 
server are decoupled (push mechanism). Further, it is 
possible to use a system (in particular a server) with a 

10 lean and modular architecture, since only one single 
kind of communication means between the clients and 
the server is necessary (only one gateway necessary) 
and all requests from the user are processed within the 
clients (on the basis of the server correlated data 

15 pushed from the server to the clients). In particular the 
feature of a modular system makes it possible to easily 
extend the system. 

[0017] For example, a user of a client may want to buy 
bread at a certain location. He therefore activates a 

20 service already available on his client (terminal) to show 
him all information about bakeries at this specific loca- 
tion. The client uses location-service linking information 
available (already received from the server) to deter- 
mine in dependency of the specific location which serv- 

25 ices are useful to offer to the user (information about a 
bakery 1000 km away should for example be of no in- 
terest). Available services may for example be present- 
ed in form of URLs pointing to respective bakery 
homepages in the internet, wherein the user can use 

30 this URLs to access the homepages, thereby getting ac- 
cess to the desired information. A rendering of this 
homepages by a browser on the client can be regarded 
as service itself. 

[0018] In a preferred embodiment, application codes 

35 and/or application engines and/ or application content 
of applications for executing said services are transmit- 
ted within said service-correlated data. Thus, a large 
flexibility is achieved, since not only location informa- 
tion/location-service linking information can be updated 

40 within the clients, but also the applications and thus the 
services itself. In the following description, the term 
"service-correlated data" may mean application code, 
application engines, application content, location infor- 
mation, location-service linking information, or any com- 

45 bination thereof. 

[0019] Preferably, the location-service linking infor- 
mation is included within the application content and/or 
application code before transmitting the application con- 
tent and/or the application code from the server to the 

so clients. However, it is also possible to transmit the loca- 
tion-service linking information separately with respect 
to the application content and/or the application code. 
This has the advantage that the inventive system can 
rapidly be deployed and can coexist well with non-loca- 

55 tion-based services since existing applications, e. g. in- 
ternet applications, can be used/reused with little effort. 
[0020] In a preferred embodiment broadcast means 
and/or the internet are used as the respective commu- 
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nication channels to realize the push mechanism) to 
transfer the service-correlated data from the server to 
the clients. This has the advantage that a flexible and 
extendible service concept is provided. In case of using 
broadcast means, there are further the advantages that 
it is easier to transfer data-intensitive service correlated 
data (location-service linking information and/or appli- 
cations), since broadcast systems tend to have higher 
bandwidths. Further, transferring costs are low. 
[0021] A positioning device connectable to the clients 
may be used to determine the actual location of clients, 
respectively, wherein the assignments between the lo- 
cation and the services and/or the steps of executing 
the services on the basis of the assigned locations are 
performed on the basis of the actual location. This ena- 
bles to deal with moving clients. 
[0022] It is further preferable to use separate commu- 
nication channels for transferring different parts of the 
service-correlated data from the server to the clients, 
respectively. For example it may be useful to transfer 
parts of the service-correlated data which have to be up- 
dated very often via a cheap communication channel 
like a broadcast system, whereas parts of the service- 
correlated data which have to be updated only several 
times may be transferred to the clients via a communi- 
cation channel which is more reliable but also more cost- 
ly- 

[0023] A client for deploying location-based services 
according to the present invention is connectable to a 
server and comprises: 

receiving means for receiving service-correlated 
data from the server on the basis of a push mech- 
anism which works independent with respect to ac- 
tivities performed on said client, 
processing means being connected to the receiving 
means for assigning locations to services and/or 
services to locations on the basis of location-service 
linking information contained within the service-cor- 
related data, and 

executing means being connected to the receiving 
means and/or the processing means for executing 
services on the client on the basis of the assign- 
ments between locations and services. 

[0024] The client may for example be a terminal, a 
hand-held, a mobile phone or the like. 
[0025] In a preferred embodiment, extracting means 
are connected between the receiving means and the 
processing means for extracting the location-service 
linking information from the service-correlated data and 
for supplying the extracted location-service linking infor- 
mation to the processing means. 
[0026] The client may further comprise a database 
being connected to the receiving means and/or process- 
ing means and/or extracting means for storing the loca- 
tion-service linking information. 
Further, the client may comprise at least one sending 



means for sending service -correlated data from the cli- 
ent to a server and/or other clients. 
[0027] The client may further comprise selecting 
means being connected to said database and executing 

5 means for selecting services to be executed on the basis 
of said location-service linking information. 
[0028] To deal with moving clients, the client may fur- 
ther comprise positioning means for determining the ac- 
tual position of the client. 

w [0029] The client may further comprise an interface 
enabling a user to access and change stored location- 
service linking information and/or to input new location- 
service linking information into the client/database. This 
enables the user to very flexible handle location-service 

is linking information and therefore to very flexible deal 
with services. The user may for example use this inter- 
face to create location information or location-service 
linking information. 

[0030] In a preferred embodiment, the receiving 
20 means of the client may comprise at least two receiving 
units for separately receiving different parts of the serv- 
ice correlated information, respectively. For example, a 
first receiving means may receive only location -service 
linking information, wherein a second receiving means 
25 may only receive application content, application code, 
etc.. This enables a very effective and flexible handling 
of services/location-service correlated data, as will be 
discussed later. 

[0031] The present invention furtherprovides a server 
30 being connectable to clients for providing the clients with 
service-correlated data needed by the clients to execute 
respective services, which comprises embedding 
means for embedding location-service linking informa- 
tion into service-correlated data and sending means for 
35 transmitting the service-correlated data to the clients on 
the basis of. a push mechanism which works independ- 
ent with respect to activities performed on said clients. 
[0032] In a preferred embodiment, the embedding 
means are means for embedding location-service link- 
40 ing information into HTML data and/or JAVA data and 
XML data and/or broadcast service data. 
[0033] The sending means of the server may com- 
prise at least two sending units connectable to different 
communication channels to transmit different parts of 
45 the service correlated data via different communication 
channels to the clients, respectively. 
[0034] Last, the present invention provides a client- 
server system for deploying location-based services, in- 
cluding a client according to the present invention and 
50 a server according to the present invention. 

[0035] Further features, embodiments and advantag- 
es of the present invention will be discussed in the fol- 
lowing description while making reference to the accom- 
panying drawings, wherein 

55 

Fig. 1 shows a preferred embodiment of a system 
according to the present invention; 
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Fig. 2 shows the embodiment of Fig. 1 with an addi- 
tional positioning means according to the 
present invention; 

Fig. 3 shows the embodiment of Fig. 1 with an addi- 
tional receiving means according to the 
present invention; 

Fig. 4 the embodiment of Fig. 1 with an additional 
persistent storage means according to the 
present invention; 

Fig. 5 the embodiment of Fig. 1 with an additional 
sending means according to the present in- 
vention; 

Fig. 6 a preferred embodiment of a client according 
to the present invention. 

[0036] In the following description, making reference 
to Fig. 1 , a preferred embodiment of a system according 
to the present invention will be discussed. 
[0037] In Fig. 1, a client 1 comprises a receiving 
means 2 and processing/executing means 3. 
[0038] At least three kinds of activities may be per- 
formed with the processing/executing means 3; 

1. Collecting location-service linking information: It 
is important to process incoming location-service 
linking information contained within service-corre- 
lated data received by the receiving means 2 (the 
format issues are discussed below). For example, 
service-correlated data, in particular location-serv- 
ice linking information, may be stored in a database 
(not shown) which may be optimized for fast retriev- 
al. 

2. Service selection by a user 4: The processing/ 
executing means 3 allows the user 4 to select from 
available services. For example, the user may 
search or filter services on the basis of a specific 
location and other criteria (e.g. a search command 
"give me all bakeries near the city center of Mun- 
ster" may yield a URL to a service (for example 
homepage) of a Bakery to preorder bread). Possi- 
ble hits can be displayed as list from which the user 
4 may select. Another example would be to display 
available services on a map, including streets and 
other geographical information. Like in a GlS-sys- 
tem, the user 4 could use search or filter operations 
to reduce the amount of data which is displayed. 
Finally, a selection of services may be connected to 
the physical reality (position) of the user 4. For ex- 
ample, when the user 4 is looking to a church near- 
by to which a sight service is linked, this service may 
be invoked. 

3. Execution of selected services: The application 
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which realizes a selected service is executed. How 
this is done depends on the respective application 
technology. When for example a service is related 
to a HTML-page, a web browser may be launched 
5 to execute this service, i. e. to render the HTML- 
page. An alternative may be to launch services au- 
tomatically depending on the user's action. For in- 
stance, when entering a certain area of a nearby 
business, the service of the business may be acti- 
ve vated automatically. This behaviour of the system 
preferably is configurable by the user 4. 

[0039] As shown in Fig. 2, the system of the present 
invention can be significantly improved using a position- 
's jng means 5 (e. g. a GPS-receiver). The positioning 
means 5 may for example be used to relate search op- 
erations to the user's position (e. g. "give me all bakeries 
within 1 km") or display the user's (client's) position on 
a map of available services. 
20 [0040] As shown in Fig. 3, another extension is to use 
several receiving means, here a first receiving means 
2 1 and a second receiving means 2 2 . This enables to 
increase the bandwidth. As already mentioned, using 
several receiving means 2 1 and 2 2 may enable to save 
25 costs. For example, a DAB-receiver as a first receiving 
means 2 1 could by used to receive location-service link- 
ing information (low transmission costs) and a mobile 
phone as a second receiving means 2 2 to receive a cor- 
responding application content (individual service). The 
30 use of several receiving means 2 V 2 2 may be opaque 
(the user is not informed which data is received from 
which receiving means) or transparent (the user is 
asked before receiving respective data as different cost 
functions are related to different receiving means), in 
35 this embodiment the first receiving means 2 1 receives 
applications as a first part of the service-correlated data, 
and the second receiving means 2 2 receives location- 
service linking information as a second part of the serv- 
ice-correlated data. 
40 [0041] In the following description section it is dis- 
cussed how applications can be tagged with location in- 
formation. 

[0042] An important aspect of the present invention is 
to associate services with location data. This could be 
45 achieved by adding location-service linking information 
to the application content or by distributing service iden- 
tifiers together with location (service id + location = link- 
ing information) data separately from the "rest" of the 
service correlated data (for example application con- 
50 tent). Generally, each piece of location-service linking 
data consists of location data and a service identifier. In 
the case that location-service linking data is embedded 
into an application content, the service identifiers may 
be left, since the application into which content the lo- 
55 cation-service linking data is embedded is already the 
service to be associated. The way how to add location- 
service linking information (location data) to the appli- 
cation content is dependent on the respective service 
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technology used, e. g.: 

For HTML-based application content location data 
could be placed inside a META-tag of one or more 
of those pages [13], 

for JAVA-application content location data may be 
added in an attribute of the MANIFEST file of an 
JAR-archive [4], 

for XML-based application content [3] separate el- 
ements might be defined to include the location da- 
ta, and 

for broadcast application content location data 
might be included in the service data (service data 
in the sense of a broadcast system). For example, 
for DAB location data is included in the FIG 0/13 
signaling of a DAB-user application. 

[0043] If the location data is distributed separately 
from the application content data, service identifiers 
may be used (cf . below). The location-service linking da- 
ta is distributed then as pairs of location data and service 
identifiers in some chosen format (e. g as XML data). 
The service-location linking data may be split up to deal 
with the characteristics of the bearer and the business 
requirements of the distributor. As it is described in [7], 
the service-location linking data may be split up into 
chunks according to frequency of use and frequency of 
updates. Additionally, the service-location linking data 
might be encrypted for a restricted service. As it is men- 
tioned for single locations (cf. below), sets of locations 
might also be generated using executable code or ex- 
ternal references. 

[0044] Locations can be defined/described as a set of 
data having the following entries: 

• A unique identifier within a given namespace. If the 
service identifier is left, the location cannot be ref- 
erenced and is considered as anonymous. 

• The actual location, which designates one or more 
areas (an area may degenerate into a position or a 
line), in one of the following formats: 

1 . Numerically: given as coordinates in relation 
to a default reference system. The reference 
system may also be designated. E. g. longitude 
and latitude of WGS84 ([12]) might be used. 

2. Symbolically: a name is used (e.g. a city 
name or a postal address). 

3. Compositionally: The location is specified in 
terms of other locations (as in ILOC [2] or AGO- 
RA [16]). 



4. Descriptive: A textual description is given of 
the location itself or how to reach the location. 
This can be done either in a free format or semi- 
formal (e.g. using XML). This is somewhat sim- 

5 ilar to a compositional format, but here is the 

emphasis to use a human readable format. 

5. Procedurally: Application code is given (for 
example received from the server) which can 

10 be executed by some (virtual) machine. The re- 

sult of executing this code is a location. For in- 
stance, a Java applet is used to determine the 
actual position of a moving object. 

15 6. Per reference: A reference to some external 

entity or some other location is given. Referenc- 
es of the first type may involve the use of loca- 
tion servers which deliver locations on demand 
(e.g. a URL is given which is resolved on a serv- 

20 er). Location references of the second type al- 

low to provide multiple service identifiers for lo- 
cations while sharing the information. 

[0045] It is also possible to provide several formats at 
25 the same time. 

•The validity of the data: 

[0046] 

30 

1 . The accuracy (e. g. using some overall quality or 
measurement) 

2. Availability: time periods are given when the lo- 
35 cation data (or better the related service) is valid. 

• The producer/distributor of the data 

• Version information 

40 

[0047] Except the entry of the actual location, all other 
entries are optional. Location information can be ex- 
tended to deal with 3D data (e. g. including the altitude 
of some position). 

45 [0048] If a service identifier has to be used, the actual 
identifier depends on the used technology. For internet- 
related content currently an URL ([1 ]) is the best choice. 
For broadcast systems like DAB an identifier specific to 
this system can be used (e. g. in DAB a component iden- 

50 tif ier and/or a MOT (Multimedia Object Transfer [23] ob- 
ject identifier). Note, also the location data itself might 
be used to designate a service ([6]). Like it is done in 
broadcast systems, additional attributes may be added 
to the service identifier (c. g. a description of the service, 

55 the service type or a specification of the needed resourc- 
es). 

[0049] In the following description section, it is dis- 
cussed how to deal with personal or community loca- 
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tion-based services. 

[0050] So far, the system is designed to handle loca- 
tion data/location-service linking data coming from out- 
side the system. But also the user 4 may have the need 
to generate location data/location-service linking data 
or to manipulate those data. The following use cases 
demonstrate this: 

1. Location-based events (e. g. [10]): The user 4 is 
notified in relation to his or her location-based ac- 
tivities. The following cases for generating an event 
can be considered: 

i. The user 4 designates one or more locations 
as hot spots. If he is entering (or is approach- 
ing) that location, an event is generated. For in- 
stance, this can be used for reminding the user 
4 of doing some task in relation to the location. 

ii. The same principle can be applied to servic- 
es. So, if a service is set to a particular location, 
a notification is sent to the user 4 (e. g. to get 
notified when someone is coming). 

iii. Finally, location changes of services can be 
notified. So, if a service moves out of some ar- 
ea, the user 4 gets a notification. This basic 
event notification can be extended to consider 
also service attributes (e. g. the user 4 is noti- 
fied when she is passing a nearby bakery). 

2. Passing location information: location-service 
linking information may be passed to other users. 
This can be similarly released to cut-and-paste of 
links to web pages. 

3. Revealing the own position: The position of the 
user 4 may be revealed (as a kind of location serv- 
ice). This can be accomplished with the use of po- 
sitioning means 5 or by asking the user 4 directly. 
The position can transferred manually as passing 
location information to other users or automatically 
as a personal location service (cf. below). 

4. Location related tasks: The user 4 may want to 
execute a series of location services, c. g. doing a 
sightseeing tour. For this, the user 4 may preselect 
several services at the same time. (He additionally 
may do the selection in a certain order which will 
determine the activation). 

The activation of these selected services can now 
be coupled with certain events (cf. above): For in- 
stance, the service is launched when he is nearby 
or immediately as a preinformation. 

5. Personal location services: Also the user 4 may 
create location services/location-service linking in- 
formation (e.g. setting a link from the location of his/ 



her home to the homepage). This can be handled 
similarly to annotations (cf. below). In difference to 
them these personal location services can be made 
available outside the client 1 if a sending means 7 
5 is used (cf. below). 

6. Bookmarking location-based services: Book- 
marks are provided by web browsers to select serv- 
ices more directly. Similarly, the location-service 

10 linking information might be bookmarked. If a user 
4 decides to bookmark a location -based service, 
the corresponding location-service linking informa- 
tion can be saved in a persistent database. Later, 
the user 4 is able to select the service directly from 

15 a view of this database (e. g. using a list or a map 
displaying only the bookmarked services). Similarly, 
it is possible to bookmark only locations. 

7. Annotations: The user 4 may annotate location- 
20 based services. This could be a textual comment or 

a marker of the service. 

As a basis the system (maybe using a position- 
ing means 5 or multiple receiving means 2 1 and 2 2 ) 
as described above can be used for these use cas- 

25 es. Depending on the use case the system may be 
extended with a persistent storage means 6 (cf . Fig- 
ure 4) and/or a sending means 7 (cf . Figure 5). Note, 
that the sending means 7 might be identical with the 
receiving means (e.g. if only a mobile phone is 

30 used). 

For making annotations, it is necessary to save 
them using the persistent storage means 6. The 
same holds for events, bookmarking locations, lo- 
cation related tasks and for setting up personal lo- 

35 cation services. A sending means 7 is especially 
useful for community services like passing location 
data to other users or revealing the own position. 

In the following description section, making ref- 
erence to Fig. 6, a preferred embodiment of the ar- 

40 ch itectu re of the client 1 (terminal) will be discussed. 

Using the architecture of the client 1 (cf. Figure 
6), all use cases described above can be per- 
formed. The client 1 comprises several devices 9, 

45 a middleware layer 8, a database management 
component 10 (also referred to a database), a LBS 
("Location-Based Services") browser 1 1 , and an ap- 
plication engine 1 2. A middleware 8 consists of sev- 
eral components, which interface accordingly to re- 

50 spective devices 9. The database management 
component 10 is responsible for the collection of the 
location-service linking information. On the applica- 
tion level there are two components: The LBS 
browser 11 providing a service selection on the ba- 

55 sis of the location-service linking information, and 
the application engine 12 being responsible for the 
execution of the services. 

The middleware layer 8 comprises a first com- 
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ponent 8., which is connected to one or more receiv- . 
ing units 2. The middleware layer 8 further compris- 
es a second component 8 2 for interfacing one or 
more sending units 7. The first component B A and 
the second component 8 2 may be merged into one s 
single component. E. g. if TCP/IP is used as a com- 
munication protocol to access and distribute infor- 
mation, it might be better to hide the capabilities of 
the different units (for example for a combination of 
DAB and GPRS) forthe sake of the application sim- io 
plicity. In this case the merged component decides 
which unit to be used. 

The middleware layer 8 further comprises a 
third component 8 3 for accessing the positioning 
means 5, which delivers the user's position. Here, '5 
also multiple positioning units might be used to im- 
prove the quality and availability of positioning. Fi- 
nally, the middleware layer 8 comprises a fourth 
component 8 4 for writing data to a storage system 
and also for reading from it. The data on the storage 20 
system is preserved even if the client 1 is switched 
off. 

A central part in this architecture 1 is the collec- 
tion of the location -service linking information. This 
is handled by the database management compo- 25 
nent 10 (DBM for short) which uses the transient 
storage of the client 1 , but may also use the persist- 
ent storage (for which no link is indicated in Figure 
6 for reasons of clarity). The DBM 10 receives the 
location-service linking information from the receiv- 30 
ing means 2 - as long it is pushed from the server. 
It integrates this information in the DBM 10. (If the 
location-service linking information is embedded in 
the service (application content) as described 
above an extraction step is needed additionally). 35 
Apart from that it provides an interface to access 
the information is stored in the DBM 10. 

The LBS browser 11 provides the selection of 
location-based services. Different methods exist for 
the presentation of these location-based services 40 
(cf. above). In all cases the LBS browser 11 will use 
the location-service linking information in the DBM 
1 0 to generate the presentation (some presentation 
methods even enable a continuous update). The 
user 4 will then be able to select a service from the 45 
presentation, which is executed using the applica- 
tion engine 1 2 (cf. below). The LBS browser 1 1 also 
is responsible for handling the personal and com- 
munity location-based services. 

The application engine 1 2 is responsible for the 50 
execution of a selected service. One realization is 
to use a web browser, so that services can be real- 
ized on the basis of web technology. It is also pos- 
sible to use different application engines 12 (e.g. 
one for stand-alone Java applications and another 55 
for web technology based applications). In this 
case, an additional component is needed to decide 
on the use of the application engine 12 when the 



service is used. 

To summarize, a client-server system for loca- 
tion-based services is provided using a push archi- 
tecture. This makes the system especially attractive 
if used together with a broadcast communication fa- 
cility. Apart from a basic system also extensions to 
add personal and community location-based serv- 
ices were discussed. An important aspect of this 
system is its modularity and scalability. Thus, the 
system provides a reasonable service if only a re- 
ceiving unit 2 is available. But it significantly im- 
proves if a positioning means 5 or further receiving 
units 2 are added. 

A central element in this system is the distribu- 
tion of the location-service linking information. This 
can for example be included in the application con- 
tent itself, but in terms of flexibility it is better to dis- 
r tribute this information separately. This has the ad- 
vantage that different pieces of location-service 
linking information can be easily reused/mixed by 
other services: For example, the system can be ex- 
tended to provide meta-services. Such services use 
available location-service linking information origi- 
nally provided for other services. E. g. a sightseeing 
guide (service) may in a first step collect (more spe- 
cific and more updated) location-service informa- 
tion originally provided for specific sight services (e. 
g. church service or museum service), and in a sec- 
ond step then using this unified location-service 
linking information as a basis for executing a com- 
plete sightseeing service. 

It is proposed to use different formats for de- 
scribing locations. This could be used to deal better 
with rapid changing/moving objects. As [2] points 
out, there is also a need for redundancy. A URL 
seems currently the best choice for the service iden- 
tifiers, but also other types of service identifiers may 
be used. 

As it was pointed out, it is not only important to 
realize an environment per se, but also to consider 
how a user 4 can adapt the system to his or her 
personal needs. Apart from personalizing the sys- 
tem, the system might also offer group-oriented 
services. E. g. depending on the role of the user 4, 
the system offers different services (e. g. users 
which pay a premium rate get other services than 
users which pay a base rate). 
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Claims 

1. Method of deploying location based services exe- 
cutable on different clients (1 ) of a client-server sys- 
tem, comprising the steps of: 

transferring service correlated data from a serv- 
er to said clients (1) on the basis of a push 
mechanism which works independent with re- 
spect to activities performed on the clients (1), 
said service correlated data including location- 
service linking information, 
processing said location -service linking infor- 
mation on the clients (1), thereby assigning lo- 
cations to services and/or services to locations, 
executing said services on the basis of said as- 
signments between locations and services. 

2. Method according to claim 1 , characterized by 

transmitting application code and/or application en- 
gines and/or application content of applications for 
executing said services within said service correlat- 
ed data. 

3. Method according to claim 2, characterized by in- 
cluding said location-service linking information 
within said application content and/or application 
code before transmitting said application content 
and/or said application code from said server to said 
clients (1). 
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4. Method according to claim 2, characterized by 

transmitting said location-service linking informa- 
tion separately with respect to said application con- 
tent and/or said application code. 

5. Method according to anyone of the preceding 
claims, characterized by using broadcast means 
or any other network as respective communication 
channels to transfer the service correlated data 
from said server to said clients (1 ). 

6. Method according to anyone of the preceding 
claims, characterized by using a positioning 
means (5) connectable to said clients (1) to deter- 
mine the actual location of said clients (1 ), wherein 
said assignments between said locations and said 
services and/or the step of executing said services 
on the basis of said assigned locations are per- 
formed on the basis of said actual location. 

7. Method according to anyone of the claims 4 to 6, 
characterized by using separate communication 
channels to separately transfer different parts of 
said service correlated data from said server to said 
clients (1), respectively. 

8. Client (1 ) for deploying location based services be- 
ing connectable to a server, comprising: 

receiving means (2) for receiving service corre- 
lated data from said server on the basis of a 
push mechanism which works independent 
with respect to activities performed on said cli- 
ent (1), 

processing means (3) being connected to said 
receiving means (2) for assigning locations to 
services and/or services to locations on the ba- 
sis of location-service linking information con- 
tained within said service correlated data, and 
executing means (3) being connected to said 
receiving means (2) and/or said processing 
means (3) for executing services on said client 
on the basis of said assignments between lo- 
cations and services. 

9. Client (1) according to claim 8, characterized by 

extracting means being connected between 
said receiving means (2) and said processing 
means (3) for extracting said location-service 
linking information from said service correlated 
data and for supplying said extracted location- 
service linking information to said processing 
means (3). 

10. Client according to claim 8 or 9, characterized by 

a database (1 0) being connected to said receiv- 



ing means and/or processing means (3) and/or 
extracting means for storing said location -serv- 
ice linking information. 

5 11. Client (1) according to claim 10, characterized by 

selecting means (11) being connected to said 
database (10) and executing means (3) for se- 
lecting services to be executed on the basis of 
10 said location-service linking information. 

12. Client (1) according to anyone of the claims 8 to 11, 
characterized by 

15 - sending means (7) for sending service correlat- 
ed data from the client (1) to a server and/or 
other clients. 

13. Client (1) according to anyone of the claims 8 to 12, 
20 characterized by 

positioning means (5) for determining the actu- 
al position of the client (1). 

25 14. Client (1) according to anyone of the claims 8 to 13, 
characterized by 

an interface for accessing and changing stored 
location-service linking information and/or for 
30 inputting new location-service linking informa- 

tion into the client (1 )/database (10). 

15. Client (1) according to anyone of the claims 8 to 14, 
characterized in that said receiving means com- 

35 prise at least two receiving units (2 V 2 2 ) receiving 
separately different parts of said service correlated 
information, respectively. 

16. Server being connectable to clients (1 ) for providing 
40 said clients (1 ) with service correlated data needed 

by said clients (1) to execute respective services, 
comprising: 

embedding means for embedding location- 
45 service linking information into said service cor- 

related data, 

sending means for transmitting said service 
correlated data to said clients on the basis of a 
push mechanism which works independent 
so with respect to activities performed on said cli- 

ents (1 ). 

17. Server according to claim 16, characerized in that 
said embedding means are means for embedding 

55 location-service linking information into HTML data 
and/or JAVA data and/or XML data and/or broad- 
cast service data. 
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1 8. Server according to claim 1 6 or 1 7, characerized in 
that said sending means comprises at least two 
sending units connectable to different communica- 
tion channels to transmit different parts of said serv- 
ice correlated data via different communication 5 
channels to the clients (1), respectively. 

19. Client-server system for deploying location-based 
services, including: 

10 

a client (1 ) according to anyone of the claims 8 
to 15, 

a server according to anyone of the claims 1 6 
to 18. 

15 

20. Computer program product, comprising computer 
program means adapted to perform at least parts 
of the method according to anyone of claims 1 to 1 
and/or to embody at least parts of the client accord- 
ing to anyone of claims 8 to 15 and/or the server 20 
according to anyone of claims 1 6 to 1 8. 
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